

# CDN边缘层：处理80%以上的静态资源请求（视频文件、图片等）
# 负载均衡层：分配请求到后端服务器集群
# 应用服务层：处理动态请求（用户认证、弹幕、点赞等）
# 缓存层：缓存热点数据减少数据库压力
# 数据库层：持久化存储核心数据
# 分布式存储层：存放海量视频文件



# 采用分布式部署的方式，部署多台服务器，把流量分流开，让每个服务器都承担一部分的并发和流量，提升整体系统的并发能力。
# 微服务拆分，其实就是把一个单体的应用，按功能单一性，拆分为多个服务模块



# 并发能力的主要方面
# 同时处理请求的数量：系统能够同时处理的用户请求或任务的数量
# 资源利用率：在并发情况下系统资源(CPU、内存、I/O等)的有效利用程度
# 响应时间：在高并发情况下系统仍能保持合理的响应速度
# 吞吐量：单位时间内系统能够成功处理的请求数量



# 影响并发能力的因素
# 硬件资源(CPU核心数、内存大小、网络带宽等)
# 软件架构设计(如是否采用微服务、异步处理等)
# 数据库设计和优化
# 负载均衡策略
# 缓存机制
# 代码质量和算法效率


# 提高并发能力的方法
# 水平扩展(增加服务器数量)
# 使用异步处理和非阻塞I/O
# 实现有效的缓存策略
# 数据库优化和读写分离
# 采用分布式架构
# 合理的线程池配置



# 分库分表
# 当单表数据量过大（如超过千万级）时，查询和写入性能会下降，此时可以采用分库分表策略：

# 水平分表（Sharding）：
# 按某个字段（如user_id）将数据分散到多个表。
# 例如：order_1, order_2, ... order_n。

# 垂直分表：
# 将不常用的字段拆分到另一张表（如user_info和user_detail）。

                # 一般使用什么维度分表：先找到业务的主题，一张企业客户信息表，就可以考虑用了客户号做为分表键，
                # 需要将同一个客户信息的数据，落到一个表中，避免触发全表路由
                # 非分表键如何查询 ： 将用户信息冗余同步到ES，同步发送到ES，然后通过ES来查询（推荐）
                                    # 方法2：还有基因法：比如非分表键可以解析出分表键出来            


# 分库：
# 按业务拆分（如order_db、user_db）。
# 按数据冷热拆分（如hot_data、cold_data）。

        # 为什么要分库
                # 业务量剧增，MySQL单机磁盘容量会撑爆，拆成多个数据库，磁盘使用率大大降低
                # 数据库连接数是有限的。在高并发的场景下，大量请求访问数据库
        # 什么要分表
                # 单表数据量非常大，存储和查询的性能就会遇到瓶颈  ------一般千万级别数据量，就需要分表
        # 什么时候考虑分库分表
                # 一般数据量千万级别，B+树索引高度就会到3层以上了    ----- 单表行数超过500万行或者单表容量超过2GB
                # 如果长时间数据量都达不到 响应的量级，   如果两级到了性能还不错，长期考虑会出现平静，及时分
                # 一些流水表、用户表等才考虑分库分表


        # 分表策略如何选择
                # range，即范围策略划分表。比如我们可以将表的主键order_id，按照从0~300万的划分为一个表，300万~600万划分到另外一个表
                                            # 有利于扩容，方便， 当发生热点数据问题时，如订单id在一张表内大量聚集
                # hash取模策略：不会存在明显的热点问题。如果未来某个时候，表数据量又到瓶颈了，需要扩容，就比较麻烦。
                # 一致性Hash：

        # 如何避免热点问题数据倾斜：ange范围+ hash哈希取模结合的分表策略，简单的做法就是：先把订单按 id range分库，然后将 库内通过 hash(id) 分表


        # 分库后，事务问题如何解决
                # 本地消息表：将分布式事务拆分成本地事务进行处理：异步场景：本地消息表或事务消息
                            # 本地消息表的基本思想是将分布式事务拆分为多个本地事务，通过异步消息和重试机制来保证最终一致性
                            # 幂等处理：消费者需要能够处理重复消息

"""
发送消息方：
        需要有一个消息表，记录着消息状态相关信息。
        业务数据和消息表在同一个数据库，即要保证它俩在同一个本地事务。
        在本地事务中处理完业务数据和写消息表操作后，通过写消息到MQ消息队列。
        消息会发到消息消费方，如果发送失败，即进行重试。

消息消费方：
        处理消息队列中的消息，完成自己的业务逻辑。
        此时如果本地事务处理成功，则表明已经处理成功了。
        如果本地事务处理失败，那么就会重试执行。
        如果是业务上面的失败，给消息生产方发送一个业务补偿消息，通知进行回滚等操作。

生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。

优点&缺点：
该方案的优点是很好地解决了分布式事务问题，实现了最终一致性。缺点是消息表会耦合到业务系统中。
"""


# 跨库Join的几种解决思路
        # 字段冗余：把需要关联的字段放入主表中，避免关联操作；比如订单表保存了卖家ID（sellerId），你把卖家名字sellerName也保存到订单表
        # 全局表：比如系统中所有模块都可能会依赖到的一些基础表（即全局表），在每个数据库中均保存一份
        # 应用层代码组装：分开多次查询，调用不同模块服务，获取到数据后，代码层进行字段计算拼装。
        # 数据抽象同步：比如A库中的a表和B库中的b表有关联，可以定时将指定的表做同步，将数据汇合聚集，生成新的表。一般可以借助ETL工具

# order by,group by等聚合函数问题: 分别在各个节点上得到结果后，再在应用程序端进行合并

# 分页：
#     将分片数据同步到搜索引擎
#     在搜索引擎中执行排序分页查询
#     返回精确结果


# 分布式ID生成：  雪花算法（Snowflake）；   数据库自增序列（不同库设置不同步长）；    Redis生成ID


# 分库 分表中间件： 
# QLAlchemy Sharding (适合ORM场景)
# ​​优点​​：与SQLAlchemy深度集成，Python原生支持
# ​​特点​​：基于SQLAlchemy的扩展，支持水平分片
# ​​适用场景​​：中小规模项目，已使用SQLAlchemy的项目

# 主从分离
# 通常来说，一台单机的MySQL服务器，可以支持500左右的TPS和10000左右的QPS，
# 即单机支撑的请求访问是有限的。因此你做了分布式部署，部署了多台机器，部署了主数据库、从数据库。
# 实时性要求不高的读请求，都去读从库，写的请求或者实时性要求高的请求，才走主库

# 使用缓存
# Redis来说，它单机就能轻轻松松应对几万的并发，你读场景的业务，可以用缓存来抗高并发


# CDN，加速静态资源访问，让用户就近获取所需内容

# 消息队列，削锋，避免流量暴涨，打垮应用系统的风险。因此一般会引入消息队列，来应对高并发的场景
# 其次，如果消息队列长度超过最大数量，可以直接抛弃用户请求或跳转到错误页面

# ElasticSearch 是一个分布式、高扩展、高实时的搜索与数据分析引擎
# 天然支撑高并发。当数据量大的时候，不用动不动就加机器扩容，分库等等，可以考虑用ES来支持简单的查询搜索、统计类的操作。

# 降级熔断
# 应对服务雪崩, 常见的做法是熔断和降级
# 当下游系统出问题时，开关打开降级，不再调用下游系统。还可以选用开源组件Hystrix来支持。

# 限流
# 限流就是控制网络接口发送或接收请求的速率，它可防止DoS攻击和限制Web爬虫。限流，也称流量控制

# 异步
# 海量秒杀请求过来时，先放到消息队列中，快速响应用户，告诉用户请求正在处理中，
# 这样就可以释放资源来处理更多的请求。秒杀请求处理完后，通知用户秒杀抢购成功或者失败


# 压力测试确定系统瓶颈
# loadrunner是一款不错的压力测试工具
# 测清楚你的系统支撑的最大并发是多少，确定系统的瓶颈点，让自己心里有底，最好预防措施。
# 压测完要分析整个调用链路，性能可能出现问题是网络层（如带宽）、Nginx层、服务层、还是数据路缓存等中间件等等。

# 扩容：比如增加从库、提升配置的方式
# 切流量：服务多机房部署，如果高并发流量来了，把流量从一个机房切换到另一个机房





# 微服务是架构解耦的​​基础思想​​，而云原生微服务是其在云时代的​​工程化实践​​，
# 通过标准化工具链（容器/K8s/服务网格）解决了传统微服务的运维痛点，
# 实现了“​​基础设施即代码​​”和“​​零接触运维​​”。选择时需权衡：若团队具备云原生技术储备且追求极致效率，选云原生微服务；
# 若需兼容历史环境或轻量化部署，传统微服务仍具价值